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1.0 INTRODUCTION 



1.0 XMJaQMJ£II!3M 



TMs document describes the process for Integration and 
development of the N03/VE product set. It is directed mainly toward 
the role of development In their Interaction with integration. 

An overview of our catalog structure is discussed first. This 
includes the residence of all the N0$/yg ©roduct's source and the 
structure of a completed/ Instil lad product set. 

The source for each product must he In NOS/VE Source Code Utility 
format* The conventions for these SCU libraries are given In 

section 3. 

Section 4 will prove useful as a guide for all of our available 
special procedures and tools. 

If a developer is transmitting a new product to integration* he 
or she must provide a short verification Job and a qulcklook test 
which are r\m after the completion o* each build cycle. The 
Instructions for this process are given in section 5. 

Sections 6 and 7 describe our devtlooraent procedures. These 
procedures were written in Arden Hills *or their operating system 
development and we h%v® adopted thesa in Sunnyvale for the products. 

Appendix A gives a summary of each contend and its parameters. 
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2.0 CATALOG STRUCTURE 



2*0 CAIALQS-SI£U£IUB& 



2 a £Qy&£E_!iAIMI£MALiaS-£IRU£IURE 

The SCU library for each product Is kept In the XNTVE catalog. 
Once integration receives a new product* the source library is 
placed into tMs catalog. From this moment or\f this will be the 
only copy ©f the source arsd the developers use this as their base 

for extracting and replacing changed decks* 

whan a developer extracts d$cks from their INTVE source* this 
subset of decks will ba in SCU format and reside on their "working 
catalog**. This Is usually a person's main catalog. 

If a number of individual developers are working on the snma 

feature or project for a product* they can set up a "feature 
catalog**. The feature catalog* i.e. another rca 1 n catalog or a 
sub-catalog* Mould contain all the decks pertaining to the project. 
Each developer would extract decks frop the source In the feature 
catalog into their individual working catalogs. See diaaran> 1. 
Section 6 discusses the procedures which work with this cataloo 
structure. 

Decks art Interlocks! when they are extracted to prevent updates 
getting lost by being overwritten by an older version o* the deck. 
Interlocks are discussed more in section 3. 
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2.0 CATALOG STRUCTURE 

2.1 SOURCE MAINTENANCE STRUCTURE 

DIAGRAM 1 

.2NTVE.PI.05.SQURCE.LIBRARY 
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: source for pr oduct** 
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.USER1*S0URCE_LIBRAP,Y .USERS. SOURCE. LIBRARY .USER3 .SOURCE.LIBR AR Y 

+— — —- — ™— ~— -+ +-.—.—.-.-.-.—.——.«-«-+ 4—-— .-.—.-—4 

J Subset of feature t 3 Source library t x Source library x 

J source library x x containing only x x containing : 

: with leeks * * deck F 1 x decks I and H * 

i A thru D 1 +— ——.—«.— ♦ 4— ——————— ♦ 

4-.—™—.- — -4 

Notes! RI Is the two-letcer product Identifier 
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2.0 CATALOG STRUCTURE 
2*1.1 THE XNTVE CATALOG 

2.1.1 TH£ INTVE CATALOG 



Each product will have i suhcataiog In the wain integration 
catalog. Each product suhcataiog will contain all the data 
necessary to maintain that product* specifically the SCU source 
library and build procedures* 

All the source libraries in the INTVE catalog are kept in a 
suhcataiog identified fey the product 1 * 2-ietter identifier followed 
by the r si ease sequence number* 

For example^ the FORTRAN products source files corresponded ultb 
the following re leas ess 

EILE- ELL£A££_ QAIE 

• Intve.f c_01«soufce_l i brery Rl.0.2 April, 1984 

. Intve.f c_02.source_1 ibr iry Rl.1.1 August* 1984 

• Intve.f c_Q3.souree_l i brary Rl.1.2 est. March* 1985 

• Intve.f c_04»sourca_i Ibrary $1.1.3 est. June* 1985 

• intve.fc_C5. source.l i brary Rl»2*l est. December* 198*> 

Of course* not all the flies are on our disk packs at one time In 

order to conserve disk space* Normally* one would find two source 

libraries f or each product on the INTVE catalog. The previous 
libraries are stored onto magnetic tapes. 

The following is a table showing each product with its 
corresponding two letter identifier* 
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2.0 CATALOG STRUCTURE 
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X!2E&XI£X£E- E&flaUCI 

AA AAH - Advanced Access Hat hod 

AP APL - A Programming Language 

CB COBOL aoaplfer 

CC CCI1 - Common Compiler Nodules 

CG CCS - Cofflffion Code Generator 

D8 DEBUG utility 

FA FHk - File Hlgration Aid 

FC FORTRAN compiler 

FL FR.TL - Fortran Puntlme Library 

FM FHU - File Management Utility 

HU HgLP - Help Utility for On-line Manuals 

LI LISP - Lisp Interpreter 

ML CUHL - Mathematics Library 

OH MANUALS - On Line Manuals 

PA PASCAL compiler 

PE PRD^RAtlNING ENVIRONMENTS 

P^ PROLOG interpreter 

SH S0RT/HER6E ut 1 1 i ty 

ST SDIT CATALOG utility 

TT TEST T10L LIBRARY - Testing Environment Utility 

IS ZEUS - A Report Generator 

Each source library in the INTVE catalog ffiust have a "latest 

changes" and a "logging" file associated with It* For example* for 

fortran's third release* the INTVE catalog would contain 

. INTVE. FC_03.S0URCE_LIBRARY* .INTVE* FC.G3. LATEST.C MANGES and 
. INTVE. F€_ 03 •LOGGING, 

The latest changes file is an SCU source library containing one 
day»s worth of updated decks located in the source library. When a 
developer wants to update code on the source library In INTVE via 
the transffiit.to.. integration procedure* the changes are located only 
on the latest changes file until the following day. Each corning* 
all of our NOS/VE product's latest changes files are combined Into 
the main source library. 

The logging f I I* contains Information about each extract of code 
or transmission of code between source libraries. 
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2 . 2 aiI4LOS-£IEy£iya£-.0£-A-£I3!i£LEI£a.£EQnyCI-i£I 

A completed product sat built by integration Is usually installed 
into the SSYSTEM catalog* If there are concurrent builds related to 
different releases* the closest release is Instilled in $SYST€H and 
the future release Is installed into the INT180 catalog* The 
$SYSTEW products ara automatically available to anyone using 
NOS/VE. To use products fronf the IHT1B0 catalog* see the SFTPC 
Copland in the Sunnyvale Tools library* described in DCS document 
S4702* 

The SSYSTEH and INT180 catalog structure consists of full product 
na.*e sub-catalogs containing run time libraries and bound Products. 
A further breakdown in structure is the maintenance catalog which 
contains files such as unbound libraries and ?saps. 

For example* a FORTRAN product installed into the SSYSTEH catalog 
would consist of thasa files? 

EILE- SESCE1EIXQM 

$system«f ortran«bound_product Fortran compiler with ail 

references to other product's 
satisfied 

Ssystsp.f ortran.f I f$ i I br ary Fortran library used during 

run time or execution 

isvstepwfortran. Fortran library created solely 

maintenance*unbound_coinponent from cybll and assemble 

hi nar les 

$syst«ro* fortran. Bound fort ran module 

maintenance* bound.c opponent 

$system*f ortran«rnalntdnanu6«map Load?uao created during the 

binding process 

$systet**f ortran. Command library containing 

maintenance* command. I ibrary fortran's program descriptions 

and error templates 

Not all products have ail these related files. Some common 
products are not bound* 

The catalog structure Is the same In the 1NT18C catalog. The 
only difference Is the wain catalog nan?e* 
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3.0 SCU LIBRARY ORGANIZATION 






3.0 scu-Liaai£i.flafiA*4i2Aiiaa 



3.1 DEcn-Q&fiiiaizAiiaa 



3.1.1 USAGE OF GROUPS 

Critical to the structure of the product's source libraries* and 
to the efficiency of the source maintenance procedures* is the 
association of SCU "group naaies" with each deck on the library. 
These groups may be used to manipulate "blocks" or "groups** of 
decks* such as ail decks In a Job template or system core library* 
f a I r ly easi I y. 

The different types of groups are identified by the conventions 
used to nasie then* Except for the "processor* and "generic" groups 
(described below)* the format of all group names 1st 

xxySaaaaaa 

where •xx 1 is the product identifier* "aaaaaa" is a descriptive nar»?a 
for the particular group* and "y" is one of the following! 

S Specifies a "Source" group* i.e. a subdivision of the 

source library into component libraries. Several 
examples of groups of this type are* 

o ss $p r o gr a m_ ) nt e r f ac e ( o s f $ p r og r a w_ I n t er f ac e ) 
f cs$f ront.and 
cbs$cobo I. source 

F Specifies a "destination File" group (i.e. a file onto 

which a deck is to be placed after processing). Several 
examples of groups of this type ar*t 

aaf$440_i ibrary 
osf$fflonltor 
osfSobJact.coda.uti 1 I ties 
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3.0 SCU LIBRARY ORGANIZATION 
3.1.1 USAGE OF GROUPS 



G Specifies a "Group* 1 * i.e. a col I set ion of decks that 

have bean decided would be useful to be able to refer to 
en masse. Several examples of groups of this type are* 

cbg$procadur^_ooiifflon_d3cks 
cbg$run_t ima_proc*dtjres 
f cg$br i d^e^eodul ms 

NOTE* All decks on the source library which belong in the library 
ps f $axternal_Jnter face_sour ce should be associated with the group 
nasie "psfSexternal.intarf ace.source". Keypoint decks snti error 
codes should also baiong to this group* 

Host other group names will follow the conventions described in 
the previous text for the product source libraries* However* there 
are two classes of groups for which this Is I nappr oor i ate* 
"processor** groups and f *ganeric w groups. 

A "processor" group will he given the sa»e name as the 
corresponding processor* #•*)• the group name for decks to he 
compiled by CYBIL will ba M CYBIL"« Other processor group names are? 

assemble 

cobo I 
pp„compass 

CP^COHPSS s 

cyb 1 l_cc 

Note that some of tliese must obviously be processed on the NOS 

side of the machine. 

A "generic** group is used in those cases where knowing the 
processor for a deck is insufficient for some nuroose. The generic 
groups that have been identified and are required* if applicable* 

are: 

common 

orogr amides er ipt i oris 

message.templ ates 

scl.procedures 

ccl^procedures 

scu.se I act longer i tar I -a 

bui !d_procs 

del etad_decks 

All decks which are called by other decks will belong to the 
group M copfi!on w . Whan a dack needs to be deleted* it should belong 



Integr atlon and Devalopm^nt Guidelines and Conventions 



3-3 
07/11/85 



3.0 SCU LIBRARY ORGANIZATION 
3.1.1 USAGE OF GSOUPS 
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to a group "deleted decks". At this point in time* the deck Is not 
really deleted* so tha build procedure must be specifically 
excluding this deck until .someone In integration can physics! 1y 
delete the deck. This will only he dona between releases to insure 
our ability to back up to a previous level. 



So?ne of these generic groups overlap 
processor groups. 



to some extent with the 



A deck may have up to Z55 group names associated with it* At 
this point In tl»e* a group cannot be associated to another group. 
A DAP has been written to allow this capability* For the time 
being* issue the change., deck SCU command to establish all deck to 
group associations. 



3*1.2 INTERLOCKS 



Among the information in an SCU deck header ere the original 
Interlock and sub-interlock fields. When a deck Is extracted from a 
source library, the sub-interlock field Is set to contain the name 
of the user which askaJ for the deck and the date and time of the 
extraction. After this sub-interlock field Is set* the deck cannot 
be extracted by anyone. 

When the sub* inter i ock field is set on the library where the deck 

resides* the deck now also resides on the source library In the 

user's catalog. The original interlock field Is set *or this deck 

on the user's source library to the sane values of the main 

library's sub-Interlock field* I.e. the user name and date and tiwe 
of extraction. 

After changes are made to this deck and it is transmitted back to 
the naln library* the transmit command used checks that these 
sub-interlock and original interlocks match between the two source 
libraries. After the transmit is complete* the two interlock fields 
are cleared. 

The following diagrams explain the interlock settings when a deck 
is extracted from the integration catalog. The first example shows 
an extraction Into the working catalog only. The second example 
shows the result of using a feature catalog. 
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3.1.2 INTERLOCKS 

Interlockss Usaga of a working catalog only* I.e. no feature catalog* 

1 2 

t •INTVE.PI.On.Sourca.Library J s *! NTV?,Pf_0n.$ourct_ll br ary s 

s Deck A : J Deck A J 

; , { 3 -— , j 

s Original * s Original * 

s Interlock! none s « Interlocks none s 

/ — Sub s / — Sub s 

s : Interlocks USER.NAHc i « : Interlocks USER.NAHE : 

i s DatasXX TlnesYY s s s DatesXX TiipesYY s 

s s •INTVE«?I_On*l.atast_Changes s 1 * •INTVE*PI_0n.l atest.Changes s 

s s Deck A s s s Deck A s 

1 1— .— — — 1 1 t— — — — — 1 

\— Original USER.NAHS: s \— Original USER_NAHE 1 

: Interlock: DatasXX TiiTiesyy s t Interlocks Date'XX TlmesYY s 

/ — Sub s s Sub s 

« t Interlocks USER.NAME s s Interlocks none s 

s s Dates XX Times"! s s s 

* 4- -+ 4- «——.«.———————.— ♦ 

S 

j 4— .————«.•«— .«-».».«.*.-.-—.— .—-4. 4.-.— —«.———«—.——«.— —4, 

i s .Work! ng_Cat al og.Sourse.Ll brar ys • «Worki ng.Catal cg.$ource_LI br ary: 

• • " "" »""•"■■ "■■■ Mi IB Bin ■!• I II — »• iiii 1111 —in -uiiMiia an in # # """ "" m bbi m bbi — — ■» bbi «•• bii 1-1 b» ■" ■ ■ "-• — •« — « "» bbi ■- bb m bbi bbi bb^ 

s s Deck A s s s 

: j--.-.™.™ 1 x Deck A does not exist on s 

\ — Original USER.NAME s : this library after trans- : 

: Interlock: DatasXX T line: 11 s s mission back to Integra- s 

s Sub s s tlon. s 

s Interlocks none s s s 

• • • • 

• • • • 

4.-««-.-.«.-.--.«.«.«.----«-.^-«-.-,----.«.«-«-.-.---4. +—••••_•_•••_•••— —••-•••_— •••.••4. 

Deck A has bean extracted into The deck has been transmitted 

the working catalog and all back to the Integration catalog. 

Interlocks have been sat* This Even though an interlock still 

deck can now be modified in the exists between the Intve latest 

working catalog. Deck A cannot changes and main source library* 

be extracted for the purposes this deck can be re-extracted by 

of making changes at this tl«ie another or the same user. 
by anyone else. 
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3 

J •INTVE«pS_On«Sourca_Library * This diagram shows the result o 

• , , — . the latest changes file haying 

: D«cK A 8 been combined with the stain 

t— «™™«. x source library. This automat I- 

s Original ? caily occurs every morning and 

s Interlocks none s is the responsibility of the 

s Sub t integration group* 

i Interlock* none s 

* . — « , + 

? «INTVE«p i_On .Lat&st.Changas s 

? — „«.. —™- «•- MMN . MM ... «.-™.- . 1 

: J 

: j 

: Empty source library 2 

* * 
: t 

: s 

• • 
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3.0 SCU LIBRARY ORGANIZATION 
3.1.2 INTERLOCKS 



Interlocks! Usage of a feature catalog. 

1 

s •INTV€.PI.On*Sourca.Llbrary s 



/- 



3 
I 



J Peck A 

: Original 

: Interlock* none 

- Sub 

s Interlock? USER.NAHS 

J DatasXX TlraeiYY 



/- 



3 



: .INTVE.PI.On.Lfitest.Changes 



: 
i 
: 
: 

•4 

: 

t Deck A 1 

j , «. — «. j 

- Original USER.NAME t 

s Interlocks DatasXX TlwetYY i 

~ Sub J 

s Interlock: USER.NAHE 2 

: Date* XX Ttm&tJl t 



Extraction of Deck A through 
the feature catalog to the work- 
ing catalog sets deck Inter- 
locks. Changes to the deck ara 
made at this time In the work I no 
catalog. Deck A cannot fee 
extracted now by anyone. 



s •Feature .Cat a! og«Source_Llbrary 



: 

s 

• 

\- 

/ 

t 

* 

t 
* 



: Deck A 

• .HI - ---- 

- Original USER.NA?1E 

: Interlocks OatesXX TiuasZZ 

- Sub 

: Interlocks USER.NAHE 

* Data J XX Times WW 



s .Work! ng_Catal og.Source^LI br ar y 



s : Deck A 

V— Original USER.NAMc 

s Interlocks Dates XX Tlme«WW 

: Sub 

s Interlocks none 

s 

+__ — ,. ™™™.- «..—- . — . 
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3.0 SCU LIBRARY ORGANIZATION 
3.1.2 INTERLOCKS 





+• 


mmm —.-.—.———»«.——— -.-.„.-.»..-.....-.«....•.. — . 


— .+ 




5 


•INTVE«PI_On«Source_Library 






5- 


—«—.-.«.-.«»«.«.«.*.«-«.— »,-.«.—. ~«. «.—-..».«.... 


— i 




• 
• 

J 


Deck A 






Original 






: 


Interlock: none 




/• 


-— 


Sub 




s 


t 


Interlocks USER.NAHE 




t 
1 

: 
i 


• 

» 


DatetXX TlneUZ 










t 

* 


• 
» 


■INTVE«PI_Gn«Lat*st_Changes 


i 


? 


Since the extraction* the 


• 

* 


t 


s 


SOURCE.LIBRARY and tfta 


: 


i 


: 


LATEST.CHANGES files Nave 


s 


• 
* 


: 


combined. Deck A is no 


: 


• 
• 


• 
• 


longer on LATEST.CHAHGES. 


t 


t 


: 




t 


* 


• 
• 




: 


• 









: •Feature.Catal og.Source_Li brar y: 



: Deck A 

- Original USER.NAME 

: Interlock: Date:XX TI?ne:ZZ 

i Sub 

: Interlock: none 



Oeck A Has transmitted back to 
the feature catalog* The deck 
can now be re-extracted Into 
another working catalog or given 
back to the INTVE catalog* 

Note the change In the Interlock on 
SOURCE. LIBRARY due to the combining 
with UTEST.CHANGES. 



: «Vlorking_Catal og. Sour ce_Li brer y: 

: ————«.-.—-.—.-.-.«.«.««.—-.». — - 1 

: : 

: Oeck A does not exist on : 

: this library after trans- : 

: mission to feature catalog. * 

: : 

: : 



Integration and Development Guidelines and Conventions 



3-8 
07/11/85 



3*0 SCU LIBRARY ORGANIZATION 
3.1.2 INTERLOCKS 



: * I NT VE * P I.On ,Sour ca_L i b r ar y 

• — — iimlrMMMM ..-.„- .— _ -■ii-,---,-.,-.--....- - 

» mm mm «b ■■ ■■■■•iiui nil i— ii»» m •alio »■■ ■» urn ia« ■« «■ «bi ij m 

J Deck A 

: —. — .— — - 

s Or I glnal 

i Interlock; none 

/— Sub 

i i Interlock: Feature.catalog 

s : Oat as XX TJ«e«7Z 

% + M-MM------—M-.---..-—-.M— — — .- — -.+ 

s 

s : •INTyE.PI.On.Latast.Cbanges 

J t Deck A 
* : — — 

\ — Original Feature_oatalog 

* Interlock? Date* XX TIsoiZZ 

i Sub 

? Interlocks none 

* 



Deck A was transmitted back to 
the Integration catalog. The 
deck could be re-extracted at 
this 1 1 me* Note that the date 
and time associated with the 
interlocks here are the stis as 
those associated between the 
source library and feature cat- 
alog source libraries in the 
previous diagram* 



+ MMM-MM MM— M—M-MMM MM- MM MMMMMMM + 

s * Feature. Cat a log* Sou roe.Library 

J — MM — — — «—.— —.—-. — -.—«-,-. MM— 

: 

s Deck A does not exist on 

t this library after the 

s transmission to tha inte- 

s gration catalog* 



+ MMMMM MMMMMMMMMM MM — MM M— M-M ^ 

•Worklng.Catai og* Source .Library 



Deck A does not exist on 
this library at this tine* 



+ -• »M — M— — — . — M- — M — MM-M— M— — -4- 
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3*0 SCU LIBRARY ORGANIZATION 
3*lmZ INTERLOCKS 



; • XNTVE«p i_On«SourcO-i br ary 

s Deck A 



s Original 

s Interlock* none 

i Sub 

s Interlock? none 

5 

4. »««-«.— ,-™™—.~~, 



4 

: 
•-I 

i 
s 

• 
• 

: 

J 

? 
} 



This diagram shows the result of 
the latest changes file hiving 
been combined with the stain 
source library* This automati- 
cally occurs every warning and 
is the responsibility of the 
integration group. 



*,XNTVE*pl_Qn.latest_Changes 



Enpty source library 



— •+ 



.-+ 
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3.0 SCU LIBRARY ORGANIZATION 
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3.2.1 HQDX*=I€ATfON CONVENTIONS 

Each change made to a deck or a group of decks on an SCU library 

Is associated with a modification name* ivary modification header 

should have information containing the author's name and a 
description of the purpose* for the change. 

The following conventions for modifications are proposed* 

• Modifications for PSR's must be named by the P$R number 
wherever possible. If this isn't possible* or if the mod 
answers mora than one PSR* the PSR number (s) must foe in 
the description. If the name is the number * it should 
still be in the description* where space permits. If a 
8SL Is associated with the PSR* tha DCS number must ba in 
the descr iption* 

• Hods f or a specific DCS document such as a DAP should be 
named by a for* of the DCS number. If the project has 
another convention* or if there are many roods associated 
with the document* the descrlotlon must contain the DCS 
number. 

• If there are several mods for a feature* the description 
of the last mod transmitted before Evaluation begins 
testing of tha feature must begin with the word "FINAL**. 
A memo or note should also be sent to the responsible 
evaiuator • 

• Descriptions of modifications which are not PSR's or 
external features must be^in with an exclamation point. 
Following the exclamation point must fee a keyword 
indicating the type of modification. We propose the 
following keywords* 

PERF - This signals that the modification Is intended to 
improve performance. Performance enhancements which 
are PSR responses must follow the convention for 
other PSR's. 

DOC - This indicates that the modifications are to 
internal documentation. 
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FMT - This appJies to all nicd J f i cat ions made to Improve 
readability of the source $q$%* Cybforning* addition 
of titles and page ejects* and many deck nan changes 
would be made by this type of modification* 

PROJ - This nould Identify changes to coda which wi 1 1 
n^%r be released. Such code would include debugging 
statements and project utilities such as table 
gener ators. 

Other keywords nil I no doubt fee added to the list* 

• Bug fixes which are not PSR'd will not foe tagged by an 
exclamation mark* Wherever possible* however* PSR»s 
shoul d foe written* 

• The build content report will list the decks modified* so 
the description does not have to do this* 

• The description beyond the tag described above* should 
be a clear description of the changes made* Complete 
sentences ^rB recommended* 

• The author field $ust be filled In* Since the 
HADE.HODIFICATION procedure sets this to the value 
specified by the SFTWE procedure* this Is no hardship* 
The full last natae Is preferred to Initials or user nawe 
only* 



3.2.2 USAGE OF FEATURES 

If a project wishes to group certain modifications* each 

modification can be assigned to the same feature* Conventions for 

feature names have not bean set up* so the project can choose their 

own names* 

If a modification doas not have a feature associated with it by 
the time It is going through an integration build* the integration 
group will give it a feature narpe BUILD.XXXX where XXXX Is the 
current product set build level* 
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3.2.3 STATES 



SCO states villi be used to indicate the degree to which a 
modi f i cat i on has bean tested. Integration* feting the owner of 
INTVE* Hi U have sola authority In upgrading the state codas higher 
than state 1. 

Stat© - 'Under Development* 

Code with state modifications resides in the feature and 
working source libraries. State is used on an 
Integration sourca library to designate a modification 
that has bean rejected. {This rejection process needs to 
be defined by Evaluation and Integration.) 

State 1 - •Testable* 

Code and test modifications will be transmitted to the 
system source library at state 1. This code has 
successfully passed the unit tests and is now ready to he 
Included on the development system. 

State 1 - •Integrated* 

Code with state 2 modifications has been formal ly 

integrated Into the base system by Integration. 

QuicHJooks aro executed. Evaluation executes the 
regression and feature testbases. 

State 3 * * Release Candidate 9 

Code with state 3 modifications has passed a set of 
criteria (e.a* stability* performance* documentation 
criteria) specified In the test plans. (This approval 
process naads to be defined hy Evaluation and 
Integration.) Tha system is installed in closed shoo. 



State 4 - 'Released* 



Code with state 4 modifications has 
re leased. 



been formal ly 



There will be no state modifications on the INTVE source 
ilbrary with the possible exception of those that have achieved a 
higher state and then been rejected for some reason. 
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Each source library in the INTVE catalog of the product sat will 
contain a version representing the build level of which the library 
was last built for the closed shop system* The level will be 
contained in the healer field of the library. These level numbers 
ere changed by the integration group* 



3.4 CQBX&lfiai-CQGE 



Copyright notices are required to be pert of every CDC software 
product. The source code for each product must include a copyright 
notice as comments within the first twenty lines such that the 
notice appears with the name of the product. The comments should be 
placed within the nodule which Is initiated first (wh«re the 
starting procedure resides). For products where this is not 
applicable* place the copyright comments In the first alphabetic 
module* This information must also be contained in the resultant 
binary of the product. The Cyber 170 convention is applicable* 
i .a. 



COPYRIGHT CONTROL HATA CORPORATION l<?xx 



It is the development project's responsibility for aenerating and 

transmitting code to include the copyright information in the 

source. Annual changes to update to the current year Is not 

required. Integration places the copyright information into the 
product's bound binary module cogent field, 

For further Information* refer to the CDC procedure on copyright 
ownership notices* policy number 10*08 sOltOll* 
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4.0 IQOLS 



Th8f 8 


are 


procedures 


for 


ifhrar ies# 


how 


prov i de« 





a fow libraries avalhhlfi which contain helpful 
everyone to access* The following is a list of these 
thty ara accessed %n6 a list of the tools thay 



4.1 SXEilQQLS-LIIi&A&X 

LIBRARY* svf$tools_i ibrary 

ACCESS* Library Is automatically in the command list when 
logged onto NOS/VE. (Available only In Sunnyvale) 

Hora information about the tools J istad below can ha obtained 
from the DCS document* S4702. 

IQOLS 

BANNER 

BURST.C0HPILATIQM.LISTIN5S 

CHQQSE 

COUNT.LINES 

CYBXREF 

FOPMAT.SmiNG 

SCOOP 

SELECT 

SENATOR 

SET_MAX?mJ?1_STACK_SIZ£ 

XEDIT 

AL A^M 

CHANGE_FEATURE 

CHANGE. GLOBAL 

CHANGE_GROUP_NANE 

CQUNT.ACTIVEJ.INES 

DETACHJJNIQUE.FILE 

niSPLAY.ALL.PERHCTS 

DISPLAY.CATAL0G.C3NTSNTS 

015 PLAY. MODI FICATIONS.BY.STATE 

DlSPLAY_NEW_MODIFICATIGNS 

EOIT.DESCRXPTIOM 

EXPAND_.SOURCE.FILE 

EXTPACT.PaOC 
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4.0 TOOLS 

4.1 SVFSTOOLS.LIBRARY 



GENERATE.8UIL0.C0NTEMT. REPORT 

GENERATE .SELECTXON.CRITERX A 

HARDCQPY 

INTEGRATE J10DIFICA7IQM 

PRINT 

PUlLJiOOIFICATIQNS 

PUT.L1STINSS.0N.S0URCE. LIBRARY 

REPORT.MODIFICATION 

SET.PPODUCT.CATALOG 

UPDATE. PRODUCT 

DIS PL AY.USER. COUNT 

LIST.8ASE 

PLOT.USERS 

OUMP.CATALOGS 

OXSPLAY.FILE.USERS 

COHPARE. BATES 

tOMPRESS.DELETE. LISTING 

SCREEN 



4.2 S£S13tE.IflQLS-LiaSAfiX-=-££L£AS£-l 

LIBRARY* SE5/VE tools library 

ACCESS: S9t.comsiand.llst Add*«sesve«stf Stool s 

IOQL- a£SCiI£IIQti 

CHANGE.REHOTE.FILE Change NOS file access 

parameters 

CHECK.HAIL Checks NOS SES and NOS/VE 

mal I box f I I es 

CREATE.NEW_NAIl.Bax Reinitializes your NOS/VE 

mai 1box 

CREATE.RENOTE.PILE.PERHITS" Sets NOS file access 

permissions 

OELFTE.REHOTE.FILE Purges NOS files 

DISPLAY.ACTIVE.USERS Displays currently lodged on 

NOS/VE users 

niSPLAY.NOS.CATALOG Displays a NOS catlist 

DISPLAY. TOO! HELP Displays parameters *nti 
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4.?. SES/VE TOOLS LIBRARY - RELFASE 1 



niSPLAY_TOOL_STJ*TUS 



EXTRACT.LJNES 



EXTRACT.STRING 



FQRHAT.TEXT 
GET. HAIL 

GgT_REHQTE_FIlE 
GENERATE_LARGE_BANNNER 

HELP 



PRINT_BANN£REDJ=ILE 

PUTJ.INE.USING 
REDO.COM HAND 

REPLACE.REMQTE.FILE 
RETRY.COMMANDS 

RUN.CADS.GRAPHICS 



explanation of a tool 

Displays a selected tool's 
current status 

Writes lines from an input file 
to an output file if the line 
contains the chosen string 

Writes strings only frow an 
Input file to the output file 
If the string is found In the 
Input file 

Runs the NOS TEXTPf?0 package 

Gets entries from NOS SES and 
NOS/VE mailboxes 

Acquires a NOS permanent file 

Puts a large letter banner at 
the beginning of a file 

Gives access to the SES/VE 
tools library online user 
manual* the NOS/VE messages 
manual* etc. 

Prints a file which has banner 
Information Included 

Produces formatted SCL output 

Re-executes previous SCL 

command* edittlng allowed 

Replaces a NOS permanent file 

Re-executes a sequence of 
commands* edittlno, allowed 

Executes the NOS/VE CADSG 

package. (This cannot 

currently be accessed because 

of a Fortran compiler 
problem*) 



RUN.LINK.JOB 



Causes a file to be transferred 
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to NOS to be executed 

&UN_N0S_JQ8 Causes a file to transferred to 

NOS to bB executed* or to any 
other linked HQS machine 

In order to access mors information regarding the tools listed 
above* enter the H£LP command after doing th« SSTCL 

A-.SFSVE«STFST00LS. 



4. % Qia££.US££UL-IQQL-Ua&A£I£S-A^AIUaLE 

Another useful library which contains tool procedures Is the 
$syst6fl>«osf$sit8_cofflnafid_i ibrary* This is automatically available 
to anyone who Is iogyad onto the NOS/VE operating system. The 
commands will not be listed here because there are so siany and they 
art used by several different groups or projects. The user can 
display the commands and access then* if nBQdtd* 

The library which contains the procedures for development to 
maintain their product's source literary is •INTVE»C0NMAND_LI8RARY« 
To access this library* the command* "Set.pr ograw.ettr ibutes 
Add-«INTVE•CQMMAN0.LI8RARY , • is executed. Usually* this contend Is 
added to the user's prolog file. 

Section 6 discusses thase procedures in »!»ore detail and includes 
sever a i examples* 
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5.0 N£H„£Eanu£i«£aMaiosE4iiaM2: 



5 . 1 EaQfiJl£I-H£AQEi-iHEa&!!lAIIflB 

The following information about a product's level ami version 
number represents Section 3.3*1.6 of the Cyber 180 System Interface 
Standard* DCS document $2106* Product's which are run Interactively 
should also conform to tftase standards. 



5,1. 1 PRODUCT VERSION NUMBER 



This number is in the form o.og and represents the product's 
release version* For release 1.1. 3# the version number for eech 
product are as follows! 

Product Version Number 

AAM 1,1 

API 1.0 

ASSEHBLE 1,1 

BASIC 1*0 

COBOL 1,2 

0E8UG 1,2 

CDIT CATALOG 1,0 

FNA 1,1 

¥!W 1.1 

FORTRAN 1,1 

HELP UTILITY 1.2 

LISP 1.1 

PASCAL 1.0 

PROGRAMMING ENVIRONMENT 1.0 

PROLOG 1.0 

SORT 1.1 

ZEUS 1.0 
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5.1 ,2 PRODUCT i£¥El 

Each product which calls CCH to generate a listing feust set the 
ccw variables* ccvSins tal I_data and ccv$product_ level* to the Julian 
date of compilation of the product* To acquire the Julian data* the 
product needs a nodule uhlch stores the current Julian date In their 
own variable* Tha value of this variable is then given to the cc» 
variables. The module can either reside on the product's source 
library or can be created and compiled within the build procedure* 
An example from a build procedure 1st 

COLLECTJTEXT install. data.cowpile unti !»**** subst i tut lon_fnark««%« 
MODULE piroSbui Id.date* 
VAR 

pivSbui Id.dates CXDCU string C5) *« 

*%$sustr ($date(ordinal )* 3* 5))%*? 
M00END pimSbul Id.datej 
** 

where pi Js the product identifier. 

Products which do not call CCH* but produce a header line when 
executed* must include the build date in the header line* Other 
products should put the build date to the job log* 



5 * t flUICHLflOILl££I-I&AliSaiIIiL-fiUia£LIMES 

If a oroduct is goln^ through the process of transmitting their 
code to integration for the first time and the evaluation group Is 
not prepared to test the product* the project roust supply a smell 
test called a quick look* 

Tf the new product can run hatch Jobs* there Is a file available 
which Is a template f^r a ouicklook test. The file narce Is 
• sv Iql .qui ck . look.tenipl ate and this can be copied into your own 
catalog and editted accordingly for your product* 

The file Is listed below. 
**** ****** ********************** ************** *********************** 

JOB Job_na!Re*xxx 

♦•XXX is the job name. This is usually the same as the test na«i?e. w 

create. var i abi e name*stats klnd*status 
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creatt.var i abi e tr oubie_? I ag kind*boolean value*false 
IF SvariabUCttviacUon* declared) * 'UNKNOWN* THEN 

create.var iabl e ttvfactlon Mnd*tstring* Siax.ntma) scope* job •• 
valuta 'KILL • 
IFEND 

IP $variable{ttvitest..tool_l Ibrary* declared) * 'UNKNOWN 1 THEM 
craate.var labl t ttv#tast_tool_l ibr ar y klnd*strlng scope* job .. 
va I u«*M$SY5T2M.$SYSTEM.VETOOL.TTF$TEST_To6l_L IBRARY* 
TFEND 

w acquire test tool library M 

* First* riiovi any prior usage. 

set.prografn.attr ibuta delete. I Ibrary** I oca I • ttf$test_tool„libr ary. • 

status* stats 
set_co?ffiand_! I st del ate*$ local •ttf$test.tool_l Ibrary status* stats 
detach. f He f\ le*$l ocal • t tfStest.too 1.1 I brar y status*stats 
attach.file f *$f nana(ttv#test_tool_l ibrary ) ♦ . 

If n*ttf$te$t_tooi. library a<n*(read execute) .* 
sffl*(read exacute) wait*true 
set.coauaand.l 1st add*$l ocai.ttf Stest.tool.l i br ar y 
set.prograw.attr lbut« ad d.l ibr ary*$t ocal .ttf $test_ tool .1 ibrary 



«t 



autonated.chdcking. routine pl«zz? status*stats 
n *z?7 Is the thrae-ietter product identifier* i «e« AA6 is the Identlfi 

*for tbe AAM product.** 

display.roessage iduss age*' CONTROL DATA COMPANY PRIVATE 1 •• 
statuses tats 

automated.checking.routine tn*xxx status*stats 
w x*x Is tbe test nasia** 

COLLECT.TEXT outpu t*taxt inp unt i i ** END .COLLECT.TEXT' status-stats 

program "This Is the program you provide to test your oroduct* 

END.CQLLECT.TEXT 
WHEN any.fault 00 

troubl a_f lag * true 

dlsplay.ioessage massa<ja**AN ERROR HAS OCCURED* status*stats 

displ ay.catalog catalog* Slocal 

d I splay. value value»osv$status outPut*$outPut 

di splay.program.attr Ibutes output* $out put 

autorcated.checki n j_r out i ne state*f ai i status*stats 
WHENEND 

"The next line would contain the compilation command for your program 
w I.e. cohol* i*taxtlnp* 1*output# lo*s*aud I t*true* b*bi naryl 

"The next line wouli contain the execute statement* i*e. an Igo or 
axacute.task bJnaryl lm*$output Ijbo*(s b ep) 
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CQLLECT.TEXT output*out unt il«» DESCRIPTION_END« status-stats 

T£$T_NAHE? xxx 

PRODUCT.NAMEi xyz 

ABSTRACT! 

DESCRIPTION? 

FEATURE! 

DESCRIPTIQN_END 

automated.checki ny.routi ne j act lon*$na$e( tt viacti on) 
JQHEND 

The program provided saust be easy to analyze end test a few 

features of the product. The output from this program must contain 

§ version number* See section 3*3 for mor% information on version 
numbers* 

If the new product is normal iy only run interactively* then a 

slmole Interactive Job must hm supplied which will display the 

product's version number and will display a distinct passing or 
f ai I Ing status* 

Once you Nave prepared a quick look Job for your product* this 
should be given to tha evaluation group to include the test in the 
quick look library* 

The purpose of the quick look tests is to verify that the products 
have been installed correct iy. The tests are run by integration 
following the completion of product set builds. 



% i miEicAiiaftLiaa-iEAasnniAi 

Every product must prowkde a Job to quickly verify the product is 

Installed* This Job differs frow the quick look test in that it is 

an extremely short test to verify that the product is callable* It 
is not designed to test any of the product's features. 

The following Is a list of guidelines for a verification Job and 

an example of an already axistlna Job for the cobo I product* 

Guidelines * 

• Put the Job Into procedure form which will be called 
i nteracti veJy. 

• Do not use any other products* 
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• Do not use any local tools* 

* Keep It "snort and sweet". Just the bare winiraujn to 
verify the existence of the product* 

* Hake the test results envious* Put comments in the job 
log to Pake the test self-explanatory* 

• Do not include error processing (WHEN loops)* Let the 
Job abort at arror* (This is the current direction! It 
may change later ♦) 

Name as follows? INSTALLATI0N.VERIFICATI0M.xx8 where 
xx*product identifier* 

Example * 

joh Job.name«instal I at ion.varl^i cat ion.cbS 

** This Is the installation verification procedure for COBOL 

** Method **> 

" 1. Create a tiny COBOL program using collect.text command 

" 2* Call COBOL compile statement to compile this Program 

** 3* Execute the binary of this program 

" 4, »C0Snt Is Installed !• should be displayed to $0UTPUT* 

oreate.var labl e (f i I e.connect Ion. status* ver if y.status) Mnd*status 

COLLFCT.TEXT output*cobol. program unti I * 'COBOL. PROGRAM.END' 

J den t J f i c at i on d I v I s I on * 

program-id* call-cobol* 

environment division. 

data division* 

procedure division* 

the-only-paragr apfu 

display "COBOL is Installed I" 
stop run* 
rOB0L.PP0GRAH.EMD 

da lete.fi I e.conoect ion st andar d.f lle«$errors flla*output •* 

status»f 1 1 e.connection. status 
cobol* i»cobol.proarareu b*cobol.lgo* I »i$i ocal *l 1st! ng*$eoi 

IF f i I e. connect! on. status. normal a true THEN 

cr eate.f I le.connectlon standard.fi la «$ errors f 1 1 e* output 

IFFND 

execute. task cobol.lgo terminat ion.error.l evel »f status*ver i f y.stat 
latach.flle f I le*( cobol.l go* cobol.progr am) 

EXIT.PROC WITH ver i f y.status 
jobend 
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The verification Job should b# givtn to integration when tht 
product is transmitted for the first time* 
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6.0 A GUIDE TO USING THE DEVELOPMENT ENVIRONMENT 



6.0 A-fiUiO£.IQ.USIlifi-Iil£.aE3«£LQEi!£iiI-£i4KI&Q!llll£l4I 



The following Is a guide to using the Development Environment 
procedures* It describes the most commonly used features* which 
should be sufficient for most situations* 



6.1 Hltt-US£-IU£S£.E&aC£aU&£S2 



The purpose in using these procedures is to provide a consistent 
juschanisffi for Development end Integration to create and control 
modification of code. Conventions are enforced by the d-eslqn of the 
Drocedures. The manual overhead of using NOS/VE and SCU is reduced 
by automatic creation of new cycles and the use of SCL variables to 
define user controllable defaults. You art required to use the 
EXTRACT. SOURCE and TaANSHIT.TO.INTEGRATIdN procedures* since these 
enforce deck interlocking. It is your option to use the other 
procedures. 



6.2 IBIIIAL-£££RJ£AIIOfl 



In your prolog* you should have two contmands which set up the 
development environment. The first nsakes the Procedures available. 
This command Is* 

s«t„.coffifn8nd_l Ibrary add««INTVE»CQMHAND_LIBRARY 

The second Is the SET.WQRKING.ENVIRONMENT co*«and« It creates 

the SCL variables which define your environment. The following 
command is an example. 

set.worklng.envirorijaeiit author^'V. E. User 1 .. 
product_name»PI..03 •• 
bui i d_l eve I* NONE work i ng_catalog*$USER 
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6*0 A GUIDE TO USING THE DEVELOPMENT ENVIRONMENT 
6.2 INITIAL PREPARATION 



In the example* the master library for the product will be 
acquired from •INTVE«PI_05«S0URCE_LIBRAPY. Your working library 
will be acquired frop $U$ER*SOURCS_LIB!URY. If It does not exist* 
It will be created the first time you execute a procedure that needs 
to write to It* If you create It yourself* make sure that you leave 
cycle one unused. This cycle Is used for temporary holding of the 
result library* You must give yourself additional permission to 
your own library. This can be done by the foil owing commands 

create.f i le.permi t $US£R«SQURCE_LIBRARY aiMall cycle *• 
control) s»«no.ne apo I icat I on^informat ion'M^ 1 

This additional file permission should also be given to your 
feature catalog source library if you have one* Be aware that 
sometimes the master catalog permissions override the file 
permissions and this w i I i cause problems* For example* If you have 
a master catalog permit for a particular user with restricted 
permissions* this will override a file permission for the group 
pub I lc* 

The APPLICATION.INFORHATION parameter is the additional 
permission* It tells 3CU that you can set interlocks on this 
library and manipulate Pods at state 4* The permit on the master 
library In INTVE should ba Ml f * Integration will Insure the 
correct permits in the INTVE catalog. 



6 • 3 £B££iaa£-Qyi_A-a££K_I3-UME-£M!2£ES 



You use the EXTRACT. SOURCE coppand to get copies o^ decks frop 
the paster library to your feature library* If another user has a 
deck checked out* you Mill not be able to acquire It* If you are 
using a feature catalog* a copy of the deck will be put there as 

we 1 1 • 

The procedure looks first on the feature library* If any* then on 
the LATEST.CHAN6ES file* and then finally on the paster library* for 
the deck. (The LATSST.CHANGES file Is regularly combined with the 
paster library* *=or EXTRACT.SOURCE you can think of the two files 
as one*) The deck is then extracted frop the library In which It 
was found* and combined with the feature library* If any* It is 
then in turn extracted from the feature library and combined with 
the working library. A new cycle Is created of the working and 
feature libraries* 
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6,3 CHECKING OUT A ^ECK^Tl HAKE c 2i N 2^S^^ 

Before concluding* the prcc Jogs the names of the decks and the 
flies on which thay were found and out to a file called LOGGING In 

the INTVE product subcatalog* 



6 . 4 gn i£&m&-TM-m&&i®u-miimmmi 



One easy way to use SCU to make changes is through the wording 
environment. Executing the £NTER_yORKING_ENyiRQNMENT command puts 
you in SCU command mode* with the high cycle of your working library 
as the BASE and cycle one ^s the RESULT, You can now enter any SCU 
command And most Devai *jpt<idnt Environment commands. 

When you are finished* and you want to save your changes* enter 
the EXIT_W0RKING_£NVIR0H*1EHT command. This will write the library 
to cycle one* end SCU* and make cycle one the new highest cycle* 
The retention period of the old high cycie will be set to 1* to keep 
file space from over flowing* 

If you do not want to save the changes* enter END NO* This will 
end SCU and cycle one *»ill be deleted. Be careful to enter EXIWE If 
you want to save your changes. To "checkpoint" your library* use 
the WRXT£_LIBRARY command, ENTER.WORKING.ENVIRONfiENT will output a 
message if cycle one already exists* 



6*5 HREAIIafi-A-flflaiEICAIIJa 



You should use the HAKE.HODIFICATTON procedure to create a new 
modification. This procedure will use the Author value specified by 
SETWE* and requires a feature name and description* If you are in 
the working environment* the modification will be added to the 
working library* If you are not in the working envi ronment* a new 
cycie of your SQURCE,LIBRARY will be created* 



6,6 £EIU&BI!!£-A-aQaiEIEa-aE£K 



When you want to return the decks you checked out with 
iXTRACT.SOURCE* you use the TRANSMIT.T0.IMTEG«ATI0N procedure* If 



\* 
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6.0 A GUIDE TO USING THE DEVCLIPHENT ENVIRONMENT 

you are using a feature catalog* you first have to use the 
T»ANSMIT_TQ_f=EATURE_CATALOG procedure. This procedure combines the 
decks specified with the existing feature library* and removes them 
from your working library* 

TRANSNIT_TQ_INTEGRATiaH reiovas the decks trow your feature 
library if you have ond# or your working library if not* It 
combines then? with a file called LATE5T..tHANGES* which is In the 
same catalog as your Piaster SOURCE.LISRARY, LATEST.CHANGES Is 
combined with SOURCE. LIBRARY automatically after deadstart. 

You can specify decks* modifications* or features to be 
transmitted* but tha efface Is always that affected decks are 
transmitted* If you specify a modi f i cat Ion* all decks changed by 
that mod are transmitted. In addition* new roods not specified will 
be Included. All mods affecting the transmitted decks which nre at 
state will be changed to state 1 by TRATI Chut not by TRATFC). 

A list of the decks transmitted* with the mods changed In state* 
Is written to the LOGGING file. 



6.7 OM£L£ 



The following example shows a simple use of the development 
environment procedures. It is assumed that the 
• INTVE.COHMAND.LIBRARY file is in the command list* and that a 
SET.WOPKING.ENVIRONHENT command has been executed. 

extr act_sour ce p lm$a_dack_of_eybi i_source 

entwe * From here on* you will get a »we/» prompt. ** 

mskm m»PI8A01X f eature*bui I d_04C0 md*»PSR fix for abort In •• 

listing generation when cross reference selected** 

edi I m«pl8a011 d*p IraSa.deck^of.cybi I. source 



Editor commands to modify the deck« 



END w or function key In screen mode * 
dism plSaOll 

"SCO 4 commands can be executed inside the environment** 
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exiwe ** creates a naw high cycle with the modification 

for^at.cybll. source s*plda01X d*pl»a$a.deck.of.cybJ I. source 

w creates another cycle* since outs I da the environment 
" This coma and is optional. 

tratl d*p I f*!$a.deck_of.cybi I. source 

Of course* you would compile the deck you modified and test it 
before transmitting it. 



6. n ilAl£Illfi^liAllS£S.aiiaailI.USIllfi-I!i£-SCU-£QliaE 



You can make changes to a deck In other ways than through the SCO 
editor by using tha GST_SOURCE and RePLACE.SOURCE procedures. 
GET. SOURCE extracts a deck and writes It out in legible format. 
REPLACE. SOURCE compares a legible file with a deck ©n the working 
library and generates a correction set. 

GET. SOURCE can be usiid for many other purposes. for this 
purpose* you wust specify EEATURES»ALL m6 3UILQ.LEVEL»NGNE to get 
si! active lines. Otherwise* GET. SOURCE may exclude some 
-modi "f I cations. 

This method of snaking changes Is post useful when using tools 
like GENERATEJ>DT and GEHERATE.CCWNAND.TABLE. MODULE . GENPDT* for 
example* accepts ^s Input a POT definition* which Is very similar to 
an SCL procedure header. Its output is a file containing CYBIi 
declarations for the parameter descriptor table. The original input 
Is listed as commentary. 

The following example shows the use o? GET.SOURCE and 

REPLACE. SOURCE to modify a deck which contains GENPDT output. As 

above* It assumes that a 3ET.W0RKING.ENVIR0NNENT command has been 
executed. 

extract. source pld$par ameter.descr lp tor. tab! a 

roake.modif ication S3999.pdt f*new. parameters •• 
md*'Add new parameters far DAP 55999. • 

get. source p idSpar am a tar. das cr I ptor. table •• 
sourceaor i ginal.pdt feature*a1 I bl*none 
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6.3 MAKING CHANGES WITHOUT USIMG THE SCU EDITOR 



*dlt_*lle original_pdt 

n extract the POT declaration frap the commentary 

generate.pdt l*orlginal.pdt e*new_pdt 

re^l ace_ssurc« source^new.pdt «* 

deck»pid$paraaeter_d4scr I ptor. table aiodlf icatlon«$5999_pdt 

transwlt.to. Integr at ion pi d$par sm«ter.descr Iptor.tab le 
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A library of comsands C mostly SCL Procedures) provides access to 
the SCO source libraries* These commands use standard facilities of 
NOS/VE and Its product sat* 

These comnands are maintained on a NQS/VE source library* Refer 
to Appendix A for cop i as of the actual procedure definitions* 

To access these commands the user wust &$d the command library to 
his/her conn and list. This Is accomplished simply by entering* 

Set.Coian.and.List add».INTVE # ComjJ?and JLI hrary 

To facilitate this* tha set„cornr8and.J 1st could be added to the 
user's prolog. As a result* the commands appear to the user to be 
system commands* 

Some of the commands described below will create a new cycle of a 
file* When this operation would take place on a temporary file that 
file will be overwritten (this is because NOS/VE does not support 
cycles for temporary files). When this operation takes place on a 
permanent file. cycle 1 of the file is first written fas a scratch 
file) and when this has successfully completed* the SNEXT cycle will 
be written and cycla 1 purged. In this way the integrity of the 
$high cycle of the library should be maintained* To facilitate 
this* users are asked to keep cycle 1 of their Source.L i br ar y file 
unused* The retention period of the previously high cycle nil be 
set tn one* Expired cycles will be deleted dally. 

The deleting of old cycles of source libraries from feature and 
working catalogs is the responsibility of the associated 
project/user* It is strongly recommended that cycles be monitored 
closely and purged regularly* as cycles can accumulate rapidly* 
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7.0 COMMANDS TO USE THE NOS/VE DEVELOPMENT ENVIRONMENT 

7.1 ENVIRONHENT COMMANDS 



7.1 Em£MI!£NX-£QJ3MtmS 



The commands described in this section are used to specify the 
"environment** in which work will he done. MOTE t All keyword 
specifications and default parameter values are defined In the 
Command Suatnary (Appendix A}* 

Particular parts of th« envi rontuent can be specified on racst of 

the coamandsj but the commands ere snuch ipore convenient to use if 

the environment parameters are established prior to work starting 
(via the Set.Working.£iiviron«ent cofnmand)* 

Normally the SET.VnRKING.ENVIRQNMENT command is called fro* 
within the user's proioj thus establishing the environment at each 
login. 

Other commands that care about an environment parameter will 
default that parameter to the value specified on the 
SET_wX1RKING_ENYIR0NH£NT command* If that command hasn't been 
called* the default used is that specified In the description of the 
corresponding parameter of the SET.WORKXNG.ENVTRONfENT command. 

Although eventually all of tha commands 
described in this document wiil be sensitive to 
whether the working environment has been 
"entered"* initially tb« only coP?*ands that will 
operate both "inside** and "outside" the working 
environiaant are COWRILE.SOURCE* GET_SOUPCE* 
REPLACE.SQURCE* AS5I6N.HQ0IFICATI0N* 

HAKE_HO!lIFICATiaH> EDtT_SOURCE> and 

FQRWAT.CYBIL.SOURCE. 

This is analogous ta the current system of using profile 
variables as defaults In the 170 SES environment. 
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7*1,1 SET_W0RKING_ENVIRQN>4ENT (SETWE) 



7,1,1 SET.WORKING.ENVIROMENT CSETWE) 



This coalman 3 Is used to create or change command language 
variables that soecify the level of system or product to bs used as 
a basis for work an! tha "feature*' and "working" catalogs being 
used. The parameters specified In this command can also be 
specified on ALL of the other commands described In this document* 
Tb*s defaults for these parameters are the same In each command, 
However* once values for then? have been established by the 
Set_Worklng_EnvlronBient conaand» they n^etS not be specified again 
unless the user wishes to acces a different catalog or build level* 

Omission of a parameter will cause a default value to be picked 
if the corresponding variable Is undefined* or if defined the 
corresponding value will be left unchanged. 

All command language variables set by this command will have a 

scooe of JOB and their names will begin with the characters WEV$» 

The variable names used are specified with the corresponding 
parameter* 

This command is normally called from a user's prolog, 

set^worklng.envl ronnent £autbor*<str lng>3 
[product_name*<nama>l 
C bu 1 1 d. I ev a I * <n am e> 1 
t too I s. I i br ar y_bu 1 1 <J_ I eve I *<name>1 
C f eature_catalog*<cata log>3 
Cfeature.bu 1 1 d_l avel«<name>1 
Cwork lng_cataloga<cat8 loo> J 
tworking.bu i 1 d_l avel 3 <name>3 
Cstatus»<status variableM 

author 1 a * specifies the caller's name* to be recorded as the 
author of any decks or modifications created by this user. 

The corresponding variable name is WEVSAUTHOR* 

Omission causes the js ar name of the caller to be used, 

product.name * pn t specifies the name of the product to be worked 
on. This is the name of the operating system or product 
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7.0 COMMANDS TO USE THE HOS/VE DEVELOPMENT ENVIRONMENT 
7*1 .1 SET.MORKING.ENVIRONMENT CSET^E) 



■ mmm WM««M*ww*wif«r* mm mmmmmmmmmi 



sufecatalog In the main integration catalog. 

The corresponding variable nawe Is WEVSP&QPUCT.NAME* 

The default Is OS. 

build.. I eve I 1 bl i specifies the name of the system or product build 
level to be used as the basis for work* 

The corresponding variable name is WEV$BUILf)„lEVEL« 

The default is the latest system build level* 

tool s_l Jhrary.bui I d_l eval ' tlbl • used for OS development only. 
Sunnyvale uses should set this parameter to NONE. 

f eatur areata log * fc 5 specifies the catalog in which the files end 
subcataiogs corresponding to a feature are located. 

The corresponding variable name is MEV$FEATUR£_CATALOG. 

The default is to hive no feature catalog <a value of •NONE 1 ). 

feature.buil d.level * fbJ * specifies the name of the feature build 
level to be used. This is analogous to the system or product 
build level but designates the version of the feature to be 
used. The initial Implementation of these commands will 
support only one "feature build level"* 

The corresponding variable nape 1s WEV$F£ATlJRE«.BUtlD_l.EVEL« 

The default is OBJECT. 

work lng_cata log * wc i specifies the catalog in which the flits and 
subcatalogs corresponding to a developers current work are 
located. 

The corresponding variable nape is WEV$Via8KXNG_CATAL0G« 

The default is to have no working catalog Ca value of 'NONE 1 ). 

work Ing.bul I d.leve I \ wbl * specifies the narpe of the working build 
level to be used. Tuis is analogous to the feature build levei 
but designates the "working" version to be used. The initial 
Implementation of these commands will support only one "working 
build level". 

The corresponding variable name is WEVSWORKING.BUILD.LEVEL. 
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T.l.l ^ll^^^^l^tl^UtVmmilmlillmmmmmmmmm 

The default is OBJECT. 
status t see NOS/VE error handling. 

7.1,2 f>ISPUY.WnRKIN6.SNVIRQN«5NT CDISVE) 



This command displays the values of the working environment 
parameters that have been established by Setjrfor ki ng.Envir enfant . 

dlsot ay_working_envi ronmeot tdisp) ay.opt ions*! Is t of <name>l 
Coutput«<f I ie>3 
Cstatus*<status y ar I ab I e>! 

disp I ay_0Pti on # di spl ay_opt ions * do * soeclfies which working 
environment parameters are to he displayed* The legal values 
for this parameters are the names of the working environment 
parameters, and their abbreviations* as specified for the 
set_Morking w enyir onment command* plus the keyword AIL meaning 
display all working environment oaraweters. 

Omission causes ALL to be used, 
output * o t specifies the file to receive the display. 

Omission causes $ OUTPUT to he used, 
status * see NOS/VE error handling. 



7.1.3 ENTER.WORKING.ENVIR-aNHHNT (ENTWE) 



This command should be used when a number of changes need to be 
made to the working source library. It calls SCU such that the base 
parameter is the source library in the working catalog and the 
result parameter is a new cycle of that source library. 

This command provides a more efficient way of doing work than 
"popping in and out* of SCU to do editing* deck expansion* etc. For 
example* a user Day enter the SCU utility, make some changes to a 
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deck* compile it (without having to exit SCU and thus write a new 
cycle of the working library)* fix whatever problems may show up in 
the compile* compile again* etc. Only when finished with that 
particular work session does the user need to leave SCU. 

Checkpoints of updates to the source library can be made via 
SCO's VJRITE.LI8RARY subcommand* Be sure to include the file nape of 
the desired resu ft. I Ibrary on the Mr ite_Li br ar y command* or the 
result will be a temporary scratch file. 

The session of work can be terminated via a corresponding call to 
EXIT_WQRKING_ENVIR0HM=NT which will write the new cycle of the 
working source library* 

enter_Morking_environmant rauthor»<strlng>1 
C pr oduct.fia»«*<na]ae>3 
Cbui id. I eve l*<naffla>3 
t featur e_cata log*<cata I og>3 
C feature^bu 1 1 d a .1dvai a <name>3 
tworking_catalog*<catalog>] 

[work ing.bu 1 1 <3 I e¥al s <nan?e>l 

tstatus*<status variable>l 

author » a s specifies the c«ller*s name* to be recorded as the 
author of any decks or modifications created by this user* 

product. nasiie * pn * specifies the system or product to be used. 

bul Id.fevel * bl * specifies the system or product build level to be 
used* 

featur e_cata log * fc : specifies the feature catalog to be used (If 
any)* 

featur e„bui I d_ level I fbl * specifies the feature build level to be 
used. 

wor king.cata log 1 wc * specifies the working catalog to be used* 

worklng.bui I d_leve I J wbl J specifies the working build level to be 
used* 

status * see NOS/VE error handling. 
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7.1.4 £XIT_WORKING_ENVIROHHENT CEXIWE) 



This command Is used to exit from the working environment created 
bv a preceding call to tha ENTER.WOPKING.FNVISOMHENT command. 

If changes have h®an made since the working environment was 
"entered" the new cycls af the working source library is written. 
If no changes were made* the new cycle is discarded. 

ex! t_workIng_envIr onmant Is tat js«<status varlable>1 

status s see NOS/VE error handling. 



7. ? C0tlfliIiDS.£aa-£flSlE-a£2£Lil£a£Bl-AliQ.ItlI£SEAIIQil 



The commands described in the following subsections are Intended 
to be used by developers <and ^valuators in their role as developers 
o? tests) and integrators to access system oriented source. 
Parameters to these cosupands are the same as corresponding 
parameters in standard system utilities such as SCU and CY8IL. For 
example the Cyoll Hst_options parameter can also be used in the 
call to the Comp i I 6_Source command. 



NOTE : All keyword specifications and default parameter values 
are defined In the Command Sumnary i Appendix A). 



7.£.1 ASSIGN.MODIFXCATIOMm CASSH) 



This command can be used Inside the Work Ing.Envl ronment. 
Remember that in SVL the HAKE_*10DIFICATION command Is recommended 
and the documentation follows this. 



This command creates me or more unique modifications in the 
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working source library. Any time the usar wishes to create or 
modify a deck* a modification ns»«e must be supplied to the 
appropriate comnand. This modification must have been created hy 
Ass! gn.Modlf icat Ion or must contain ell information required by 
Assi gn^tpodif i cat ion. 

The names for the mod If icat Ions are created fr®m the 
"rnodif icat ion name sued" assigned to a user upon Joining the 
project* and sequence number maintained in the user f s prolog. This 
command will update the sequence number in th§ prolog* thus keeping 
track of rood if icat Ion namas already used. 

The user isust initiate this tracking scheme hy entering the 
following two lines in his/her prolog* 

create_variable WEVSMODIFICATION.INOEX kind-integer .. 
scope* Job value«l (or whatever nuwber desired to start! 

create.vari able wevSmodif i catlon_in it ial s kind*strlng .. 
scope* job value" , xyz_' (xyz Is user's Jnitiais) 

The new version of the source library is writtan as the next 
cycle of the file. 

ass i gn.iaodlf icat Ion f aatur e*<name> 
Ccount*<integer>3 

C mod if i cation.descr i?t ion*<str ing>3 
Coutout»<f i le>3 
C author »<st r i ng>3 
C work ing_cata log«<cat« i og>3 
Cstatus«<status variable>l 

feature ? f ? specifies the feature with which the rood if icat Ions are 
to be associated. 

count * c * specifies the number of modifications to be assigned. 

Omission causes 1 to be used. 

modlf icatlon.descr Iptlon 1 md J specifies a brief description of the 
mod if icat ions. 

Omission causes no Inscription to be used. 

output » o t specifies the file to which are written the names of 
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7,0 COMMANDS TO USE THE NJ5/VE DEVELOPMENT ENVIRONMENT 
7.?.1 ASSIGN.HO0IPICATI0MCS) «ASSM) 

M«wMiw«><ii«rM)»««»«ri»ifM#*Mf* : <f«<iw« m m mm m at mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm 

the modifications that have been created. 

Omission causes SOUTPUT to be used* 

author t a s specifics the creator of the contents of the 
mod If Icatlons* 

wor Mng.cata log 1 wo * specifies the working catalog to be used* 

status s see NOS/VE error handling, 

7.2.2 MAKE.MODIFICATION (HAKW) 

This command can be usad Inside the Worklng.Env I ronmant • 

This command Is similar to the ASSXGN.MOOIFICATION command 
previously described EXCcPT that there is no "rood if I cat ion name 
s$®d"m Ths modification name desired must ba specified because It 
is not automatically created* 

The command creates a unique modification In the working source 
library. As with assl gn.modif Icaton* do not use this to create a 
modification on the working library If the modification exists 
already on the base (.intve.) source.! I brary from which the working 
library was extracted* An error will not be generated until 
"transiuit-to-integratlon time" if this Is the case* 

Consistent with the standards for modifications* the description 
and feature fields are required* 

makt.modlf icat ion modi f J cat i on»<name> 
f eature»<name> 

modlfl cation. descript i on« list of <strlng> 
t author »<str I ng>3 
j[working_cata log«<c*ta \ og>l 
t status*<status variable>3 

mod if I cat ion ? m » modification name deslredi should generally be 
the PSP number associated with the modlfl caton* 

feature * f * specifies the feature with which the modifications are 
to be associated* 

modi f I cat lon.descr Ipt J on \ aid s specifies a brief description of the 
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7.0 COMMANDS TO USE THE NOS/VE DEVELOPMENT ENVIRONMENT 
lmZ.2 HAKE.MODIFICATIQN CMAKH) 

modification. 

author I a t specifies the creator of the contents of the 
modifications} should contain the creator's first two Initials 
and full last name* If this field is not supplied* the working 
environment specification Is substituted. 

wor kl ng^catalog * wo t specifies the working catalog to be usad. 

status J see NOS/VE error handling. 



7,2.3 CREATE.S3IJRCE (CPES) 

This conmand can NOT b& used Inside the Work! ng_Env Ironment. 

This command creates o*ie or «iore decks In all levels of the data 
base. Checks are made to insure that the decks don't already 
exist. 

The effect of the command Is to create the new decks In the 
system or product soured library* then to extract the decks to the 
feature level and from there to the working level with appropriate 
Interlocks set along the Nay. Once this Is accomplished the text of 
the deck may be added via EDIT.IIBRARY or EDIT.SdURCE* or 
i Indirectly) any other alitor. 

The new version of a*i affected source library Is written as the 
next cycle of the corresponding file. 

create.source deek«Mst of <naP!e> 
m odi f Icat I on« <name> 
source (- group*<name> 
destlnation_aroup»l 1st of <name> 
Cgroup*llst of <na»e>3 
Cprocessor»<strlng>3 
C author *<str I ng>3 
t decked escr lotion a <str ing>3 
I expand «<booi ean>l 
Csai?!e_as*<narae>3 
C pr oduc t.name s <n a ma> 3 
I f eatur e.cataiog*<cata i og>3 
£worklng..catalod*<cata log>3 
[ status»<status variabla>3 
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Zmlmlm^mllli^Mmimmmm^mlmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm 

deck J decks 1 d s specifies the decks to be created* 

modification I m t specifies the modification under which the decks 
are to be Introduced* This modification must exist in the 
working library at state 0* 

source.group i sg i specif fas the group of decks to which the new 
decks are to b& assigned* such as QSSSSQURCE* The name rcust 
fellow the convention for source groups* i*e. It must have 
*$$" In the third and fourth positions* (See the section on 
"use of groups** <ibovj.) 

This parameter is required 

destlnatlon.group I dastinatlon.groups J dg * specifies the flieCs) 
In which the "processed" (compiled* assembled* etc*) form of 
the modules is to be placed* (See Appendix 8 1 If this is not 
applicable (In the case of a coupon deck! NONE should be 
specified* If specified* the nasse must have "F$** In the third 
and fourth positions* 

group J groups 1 g t specifies the "arbitrary" groups to which the 
decks are to be assigned* (See Appendix B) 

Opisslon causes no ^arbitrary" groups to he assigned* 
processor « o » specifies the processor for the decks* 

Owisslon causes CYBIL to be used, 
author * a t specifies tha creator of the contents of the decks* 
deck.descr iptlon « dd : specifies a brief description of the decks* 

Omission causes no description to be used. 

expand i e : specifies whether the decks are to be "directly 
expandable" I.e. written directly to a compile file 
{ expand»true) or expandable only by being the object of a SCU 
*copy or *copyc text embedded directive ( expand*f else). U*e* 
a common deck) 

Omission causes a default to be chosen according to the syntax 
of the deck name (each deck will have its own default). If the 
fourth character of the deck nawe is "$" and the third 
character Is not f, r1 , »> the default Is FALSE; otherwise the 
default Is T3UE. 

saroe^as * sa i specifies that SCU deck attributes not specified with 
parameters above are to be taken from the named deck. 
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7.0 COMMANDS TO USE THE NOS/VE DEVELOPMENT ENVIRONMENT 



7.?. 3 CREATE.SHURCE (CRE5) 



Omission cays as the normal SCU defaults to be used. 

pro^uct.nane X pn i specifies the system or product to be used. 

feature.cataloj * fc '• specifies the feature catalog to be used (If 
any). 

wor king^oatalog 1 wc J spaclfies the working catalog to be used. 

status « see NOS/VE error handling. 

7.*.* EXTRACT.50URCE CEXTS) 

This command can NOT bt used inside this Working_Env Ironwent* 

This command Is used to extract decks fro» the feature or 
sys tera/product lava! to the working level In preparation for making 
changes. In addition to the decks tbemselvesf the relevant "parts" 
o* all associated modlf {cations* features antS groups are extracted 
(i.e. SCIHs EXTRACT.SaURCE.UBRARY facility is used). 

If a deck does not exist at the feature level it is first 
extracted from the systen/product level to the feature level. 

This extraction is performed using deck Inter lockst unless 
inter I cck*fa Ise. The interlock name used is always the user na*e. 
If a deck Is extracted without Interlocks it cannot be transmitted 
back to integration or a feature catalog. 

The new version of an affected source library is written as the 
next cycle of the corresponding file. 

At least one of the deck and sel act i on_cr 1 ter ia parameters must 
be provided. If both are given the deck parameter Is processed 
first* Currently tba select! on.cr iter la parameter is not 

implemented* 

extract.source tdeck»list of <na?ae>3 
C Inter I ock a «<bool ean>3 
Cselect longer iter la*<f i ie>3 
Cproduct_naiiie*<naine>2 
Cbul ld_level«<riarae>J 
I ftatur areata log*<cita I og>,1 
Cwork I ng_c«talog»<cata I og>l 
Cstatus a <status varlable>l 
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deck t decks \ d J specifies the decks to be extracted* 

Interlock » I s .specifies whether decks are to ha extracted with or 
without Interlocks. 

Omission causes TRUE to be used* 

sel act longer iter Ja * so i specifies the file containing SCU 
selection criteria commands that alone or in conjunction with 
the decks parameter select the decks to be extracted. 

Omission causes INULL to be used* 

product_name I pn * specifies the system or product to be used. 

buiid_!evel ? bl i specifies the system or product bulld.level to be 
ms^4 when extracting decks without interlock* When decks are 
extracted with Inter lock* all active lines are Included* 

feature. catalog J fc t specifies the feature catalog to be used (If 
any). 

worklng.catalog • wc * specifies the working catalog tc be used. 

status s see NQS/VE error handling* 



7.?. ?> EDIT_SOUP.CE <EDXS) 

This command can be us#d inside the Working.Environment. 

This command Is us-ed to modify a deck that resides on the working 
source I Ibrary. 

The result of the editing will appear on a new cycle of the 
working source library. 

adit_source modif I cation 3 <name> 
i dack a <nariie>] 
t output *<f I le>l 
T, work lng_cata!cg»<catalog>! 
tstatus*<st atus variable>3 



modification ! m i specifies the modification to be used for editing 
the decks. The modification must exist In state on the 
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working library* 

deck \ d $ specifies the deck to be edited* 

Omission will necessitate selection of the deck {deck) to be 

edited from within the editor via the Select_Deck command* 

output 1 o i specifics the flit to receive displays from the 
editor* 

Omission causes SOUTPUT to be used. 

*orking_c8ta!o3 1 wc * specifies the working catalog to be used* 

status 5 see NOS/VE error handling* 

7,2,6 6ET.S0URCE (GETS) 

This command can be usad Inside the Working_Env lr onmant* 

This command writes one or wore decks to a legible file. The 
decks pay be written In expanded ( EXPAND_DECK) or unexpended 
(EVTRACT^DECKJ form. 

The decks are taken from the Source library without Interlocks* 
thus allowing the user to include (or exclude) any modlf Icat I ons or 
features desired. This command allows the user to look at source 
that nay already be Interlocked by someone else* for Informational 
purposes only* or for editing by a non-SCU editor* 

At least one of thu deck and sal ect lon.cr I ter la parameters must 
be provided* If both are given tht deck parameter Is processed 
first* 

NOTE J Refer to the description of comp 1 1 e_source for the deck 
selection and criteria file processing* 

CAUTION t If you are using GET.SOURCE to extract a deck which will be 
modified and replaced with PEPLACE_SOURCE* be sure to 
specify FEATURE-ALL and 8UIl0.LEVEt*N0NE* Otherwise* setae 
modifications way be omitted and not all active lines 
written to the source file* 

$et_source Cdack*! 1st of <nawe>1 
Csource»<f I le>1 
Cselect ion_cri ter ia*<f i ie>3 
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C inelude.l«test.ctianges*<bool ean>l 

Eexpand*<bonl ean>3 

[sxpsns ion_depth«<integer>1 

Cal ternata_pro4uot«l ist of list of <na»e>3 

C al ternatd.base* J 1st of <file>1 

Cproduct.naiB8*<na«ie>3 

C b u i 1 d_ I # v « I ■ <n am a> 3 

£ f eatur e.cata 1 og*<cata I cg>3 

Cf eatur e.bui I d_l evel*<name>3 

I wo r k i n g_ca ta I a g« <c at a I og>1 

Cworking.buil d_levei*<nani9>3 

£status*<status var tab le>l 
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deck * decks I d J specifies the decks to be written* 

source J s J specifies the file to receive the decks* 

Omission causes a file named for the first specified deck to be 
written in the working catalog. 

se J act longer iter i a » sc t specifies the file containing SCU 
selection criteria commands that alone or in conjunction with 
the decks parameter select the decks to be written. 

Omission causes $NULL to be used* 

Incl ude_l atest_changas ? He s specifies whether code recently 
transmitted to integration by other developers should be 
Included in tha decks to be written* 

Gnisslon causes FALSE to be used* 

expand * e t specifies whether the decks Bre to be expanded. 

Omission causes FALSE to be used. 

exoans ion_daptb J ed * specifies the number of levels o* COPY and 
COPYC directives to process. 

Omission causes $max.intejer to be used. 

alternata.pr oduct • ap * specifies other product catalogs in which 
to find source. J Jbrar ies to be used as a! ternate_bases in the 
exoans Ion of the coda* This parameter accepts el the single 
names or pairs of names as values. If an entry is a single 
value* It specifies an alternate product name* If a pair of 
values Is specif lad* the second element specifies the build 
level for the alternate product* If the second value is NONE 
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or only t single value is specified* a build level of HONE Is 

assumed. 

Omission causes no at tarnata.products to be accessed* 

al ternate_base * ab s specifies other files that may be required to 
properly expand the desired decks. 

Omission causes HONS to be used* 

product.nane i pn J specifies the system or product t© be used. 

build.level I bl t specifies the system or product build level to be 

used, 

feature. catalog J fc t specifies the feature catalog to be used (if 
any) • 

feature.bui I d. level J fbj : specifies the feature build level to be 
used* 

wor 'k ing_cata log * wc s specifies the working catalog to be used. 

worklng.bul I d.levei ' wbl * specifies the working build level to be 
used* 

status J see NOS/VE error handling. 



7. 2*7 REPLACE_50URCE (REPS) 

This command can be us-ad Inside the Work! ng.Env ironment • 

This command Is used to update a deck on the working source 
library* The new version of a deck on a file is compared with the 
old version on the working library using SCU's 

generate_edl t_cofn«ands facility. The SCU editor Is then Invoked to 
apofy the resulting edit commands* 

This command* in conjunction with the get.source command* 
provides the mechanism for making changes to a deck that bt^ 
difficult to make by direct use of the SCU editor* The best example 
of this Is automated formatting of source code. 

Tb& new version of the working source library Is written as the 
next cycle of the file* 



7-17 
Integration and Development Guidelines and Conventions 

07/11/85 

mmmmmmmmmmmm mm mm mm mm mm mmmmmmmmmmmmmmmm mm mmmmmmmmmmmmmmmmmmmmmmmmmmmm 

7.0 CGHHANDS TO USE THE m$/V£ DEVELOPMENT ENVIRONMENT 

CAUTION* If you used GET.SQURCE to obtain the source filet vou 
should have specified FEATURE-ALL and BUILD.LEVEL«NONE* 
Otherwise* sone modifications may fee missing. 

reo I ace. source source* <fi 1 1> 
deck«<nai«e> 
mod if icat ion*<name> 

[working.catalog-<catal og>3 
t status*<st&tus variable>3 

source * s * specifies th* file which contains the new version of 
the deck* 

deck J d i specifies th« deck to be updated. 

modification # m t specifies the modification under which the update 
Is to fee made. The modification must exist in state on the 
working source library* 

working. cats log * wc ? specifies the working catalog to foe used* 

status * see HOS/VE error handling. 



7. Z. 3 FORNAT.CYBIl.SOURCE (fORCSI 

This command can be used Inside the Working. Environments 

This conn and formats a CYBIL source deck. 

It calls GET.SOURCE to retrieve the deck* CYBFORM to do the 
formatting* and REPLACE. SOURCE to Incorporate the changes wade by 
CY&FQRfU 

If CYSFORH detects an error the replacement is suppressed. 

format. cyb i 1 .source deck 3 <na«?e> 
mod If icat ion*<name> 
C working. cat a log*<cata I og>1 
£status*<status variable>l 

deck \ d i specifies the Jack to be formatted* 
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modification * m s specifies the modJf leatlon under which the update 
is to ba made. Th% modification must exist in state on the 
working source library* 

working.cataiog 1 wo * specifies the working catalog to be used. ' 

status s see NOS/VE error handling* 



7.2.9 CDHPILE_S0U»CE (CONS) 

This Copland can be usud inside the Working. Environment* 
This command compiles/assembles one or more decks. 

The defaults have ba$n chosen for convenience of developers who 
will typically be dealing with a small number of modules at a tlroe* 

The SCU libraries Included In the list to be searched will be 
done so in the following orders 

Working library (if a working catalog is in effect) 
Feature library Cif a feature catalog is In effect) 
- Alternate bases Cif al tarnate. basts are specified) 

Latest changes Cif inc lude. I atest. changes is specified) 

OS or product source i ibrary 

Product libraries (if alternate. products are specified) 

At least one of tha leek and select Ion. cr iter i a parameters must 
be provided. If both are given the deck parameter Is processed 
first. Currently* if Just the select longer iter la parameter Is 
given* the processor and object. I ibrar y *nust also be supplied* 

Decks to be comojljj are specified only be the DECK parameter and 

by the INCLUDE.OECK and INCLUDE.GRGUP directives of the user 
seclection criteria file (specified by the SELECTION.C*ITEPIA 
parameter). Modifications to ha applied against the selected decks 
BrB selected by the BUILD.LEVEL and FEATURE parameters an by 
directives In the user selection criteria file* The 
INCLUDE. LATEST.CHANGES parameter Indicates whether or not the 
LATEST.CHANGES file in the product catalog Is to be Included as an 
alternate base. 

The selection of decks and modifications Is passed en to the SCU 
EXPAND. DECK command (by this PROC) by parameter values on the 
command call and by the selection criteria file which this proc 
always builds — • whether or not the SSLECTION.CRITERIA parameter is 
specified on the proc call. As a result of the call to SCU by this 
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PROC* the following operations are performed* 



1* The various source libraries specified ara merged. That Is* 
certain directories such as the deck directories and the 
modi f I cation directories *row the various libraries are 
merged. A -deck which appears on more than one library Is 
selected from the first library on which It Is located. 
However.* modification headers which may appear on .more than 
one library are selected fr frop the last library 
encountered* 

2. AH modifications resulting from the merge nr^ flagged as 
"included**! all decks* "excluded*. 

3. All modifications in state or 1 are excluded. This step Is 
performed because there may be pods in these states which «ay 
be of no Interest to the caller (they may even be w bad H ). 
This does moan that the current mods you are generating and 
testing will be excluded since they are in state 0j however* 
your nods will be added later either by the feature or 
selection criteria parameter* 

4. The directories are "rolled hack** to the specified build level 

- that Is* all new &ods Included In builds after the specified 
build are excluded. The directories should now be In the same 
configuration they were in when the build of the specified 
level was generated. This step is sklpoed if the value of the 
RUILD.LEVEl parameter is NONE. 

5. Modifications associated with the features specified by the 
FEATURE parameter are now w lnc luded**. If the FEATURE 
parameter is not specified* the features selected will be 
those in the WEF$r£.ATURE_LIST file of the working catalog. If 
this file does not exist or Is empty and no value Is specified 
for the FEATURE parameter* than no additional modifications 
will be Included by this step. If the FEATURE parameter is 
given the keyword value of ALL* then step 3 Is essentially 
undone - that Is* all modifications with state or 1 are 
Included* If the FEATURE parameter is given the keyword value 
of HONE this stap will result in no changes - that is* no 
modification introduced after the specified build level will 
be included. 

6. Decks specified by tfie HECK parameter are now included. Note 
that these are the only decks which have bee selected for 
co««pi I at Ion. 

7. Tha SCO selection criteria file soecifled by the 
SELECTION.CRITERIA parameter Is now processed. The directives 
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In this file may - intentially or inadvertantly - undo son?© of 
what Has bean done before. 

8« Unless both the PROCESSOR and 0BJECT.LI8RARY parameters are 
specified on the cal I to COHPILE.SOURCE* the PROC wit! Include 
some directives \\®r% to determine those values for the deck(s) 
under consideration* 

Specifying both the PROCESSOR and OB JECT.LI8RARY parameters 
causes all decks to be expanded and then compiled together* This Is 
quicker than having the procedure determine processor and object 
library for each deck If there are a lot of them. 

yhen the procedure is run a sub.catalog. called 

como i I at ion.cata log is created in the work ing.catalog* As the 
modules are processed the object.text C 1 go file) Is written to a 
file in this catalog* Th* file name Is the sam* as the destination 
ohject.,1 iferary which ^ill be written to the pslntenance 
sub_catalog* Upon successful generation of the object.! ibrary* the 
object. text file is deleted, If there are no other files In the 
compi I atlon.catafog sub.catalog* it Is deleted also* 

co«p1 1 e. source C deck*! 1st of <nawe>l 
[select Jon.cr iter la*<f i le>3 
I include.! atest.changes*<boe!aan>3 
Cfeature a l 1st of <nasie>3 
Ccoiipl le»<f I le>] 
I processor* <string>3 
Cob ject.l Ibrary*! 1st of <nai?*e>3 
Cllst-<fl!«>] 

t i 1st. opt ions»l 1st of <iist option>3 
Csave.l tstlngs*! ist of <save optionM 
t alternate. product«l ist of list of<name>3 
C al ternate.base*! 1st of <fi1e>3 
[product. naroe*<na?!»e>3 
f eature.cat al oj*<catal og>3 
Cfeature.bul I d. level »<name>3 
Cworking - cataiog*<cita loo>3 
Cworking.bu 1 1 d.l evel 3s <name>3 
Cstatus«<status variable>3 

deck J decks I d * specifies the decks to be compiled. 

$ei ection.cr Iter fa ' so * specifies the file containing SCU 
selection criteria commands that alone or in conjunction with 
the decks parameter select the decks to be compiled, 
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Omission causes SHULL to he used. 

NOTE* The selection or i ter i a fife cannot ha an Interactive 
flit. It must not contain an "END** directive. 

Include. latest.changss \ lie * specifies whether code recently 
transmitted to Integration by other developers should be 
included in the decks to be compiled. 

Omission causes FALSE to be used. 

feature * f * specifies what features are to be Included when 
compiling specified decks. The keywords ALL and NONE are also 
allowable values. 

Omission causes file W£F$F€ATUP£„LIST In the user's working 
catalog to be used If it exists. This file Is maintained by 
the ASSIGN.HODIFICATION and NAKE.HODIFICATIQN procedures. 

compile I c J specifies the name of the compile fife to be 
generated. It Is not disturbed when the procedure completes. 

Omission causes a unlaue name to be used and the file to be 

detached whsn the procedure completes. 

processor I p * specifies the compiler or assembler to be used to 
process each deck. Processor options may be selected by giving 
this parameter as a string <e.g. f CY3IL 0P»HIGH'). 

Omission causes each deck to be processed according to its 
"processor" attribute. Obviously the procedure will be more 
efficient if a processor is specified* as It will not have to 
process each deck i rid I vidua! i y* 

oh Ject.i ibrary » object.! i braries ? of * specifies the object 
libraries In the working catalog into which the 
complied/assembled modules will be placed. If sn object 
library already exists the newly compiled modules are combined 
with it to form a new version of the library which effectively 
overwrites the original. If NONE Is specified* no 
object.! Ibrary or object.fi la will be written. 

Omission causes the object libraries to be selected according 
to each deck's "destination group" attributes. 

list J I J specifies tha file to which the compilation or assembly 
listings are to be written. 
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Omission causes SLI3T to be used* {Warning - in a bitch job 
SLIST Is connected ta OUTPUT* If a listing Is not das i red In a 
batch job* $NULL should be specified for list.) 

Ilst.optlon ' llst.options 1 \o * specifies the listing options to 
be used on each call to a corael ler/asse^bl tr • Set the 
documentation for each "processor** for valid notions. 

Omission causes (3*R) to be used* I.e. a listing of the source 
and a cross reference (excluding unreferenced identifiers). 
save_l istings I si s specifies whether listings generated by 
processors are to be saved on an SCU library called 
LISTING_LI8£ARY 1 n the working catalog. Options are ALL* GOOD. 
BAD* and NONE. GOOD and BAD refer to the presence or absence 
of compilation errors. 

Omission causes MQHE to ba used* 

al ternate_product ! altar nate. products » ao s specifies other 
product catalogs in which to find source.i ibrar ies to be used 
as a1t«rnste.bases in the expansion of the code. This 

parameter accepts either single names or pairs of nai»es as 
values. If an entry is a single value* it specifies an 
alternate product name* If a pair of values is specified* the 
second element specifies the build level for the alternate 
product. If tha second value is NONE or only a single value 
specified* a build level of HONE* which iseans all active lines 
at state Z or higher* is assumed* 

Omission causes no al ternate^products to be accessed* 

a? ternate_base ? al ternat e_bases J ab J specifies other files that 
may be required to properly expand the desired decks* 

Omission causes HOME to be used* 

pr oduct.nawe 1 pn s specifies the system or product to be used* 

bulld.level I bt i specifies the system or product build level to be 
used* 

feature_cata log 1 fc : specifies the feature catalog to he used (If 
any). 

featur e_bul I d_leve I i fbl * specifies the feature build level to be 
used* 

**orking_cata log 1 wc * specifies the working catalog to be used. 
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working. bull d_!§val I wbl * spacifles the working build level to b< 
used* 

status t set N05/VE error handling* 



7.2,10 TRANS*IT_TQJ=EATURE_.CATALQ<5 CTSATFC) 

This command can HOT b& used Inside the Work I ng_£nv Ironment, 

This command transmits code (decks* modi f feat Ions * features) from 
« working catalog to a feature catalog. 

Once the transmitted coda has bean written to Its destination* It 
Is reiaovad frop Its source to free the Interlock on the deck. The 
new version of an affected source library is written as the next 
cycle of the corresponding file, NOTE s The transmitted source Is 
still available* however Interlocked* In the prey ious Iv-hl ghest 
cycle of the working catalog. 

At least one of the Jack* modification* or feature parameters 
must he provided. If more than one of them is given they ar% 
processed In the or isr Just listed, 

Unlike when directly using SCU* e.g. in a selection criteria 

•'lie* selecting a modification or feature via this commands 

parameters will result in selection of ail decks affected by that 
modification or 'eature, 

transral t_to_f eatur a_catalog Cdecks»Jist of <nama>l 
tmodlf I cat! on«l Is t of <nai*e>] 
t feature*! 1st of <name>l 
t f eatur a_catalog*<cata I og>1 
C work! ng.cata log*<c*ita I og>3 
Cstatus*<status variable>3 



deck J decks J d t specifies the decks to be transmitted* 

modification J trod If icat!on.s « m J specifies the modifications to be 
transml ttad* 

feature S features • f s specifies the features to be transmitted, 

featura_cata log ' fc i specifies the feature catalog to be used. 
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wor king. catalog * wo J specifies the working catalog to be used* 

status J set NOS/VE error handling* 



7.2.11 TRANSHIT.TO.INTEGRATION CTRATX) 

This command can HOT b® used Inside the Working_Envlr©npent* 

This cosissand transmits coda (decks* podif feat Ions* features) fron 
a feature or (If no feature catalog Is being used) working catalog* 

Once the transmitted code has been written to its destination* it 
Is removed from Its source to free the interlock on the deck* The 
new version of an affected source library Is written as the next 
cycle of the corresponding file. NOTE * The transmitted source is 
still available* however interlocked* In the previously-highest 
cycle of the feature Cor working) catalog* 

At least one of the deck* modification* or feature parameters 
aust he provided* If wore than one of them Is given they are 
processed In the order just listed* 

Unlike when directly using SCU* a*g. in a selection criteria 

file* selecting a Modification or feature via this commands 

parameters will result in selection of all decks affected by that 
modification or feature* 



transmi t_to_intagr at ion £decks*llst of <na*ne>1 
troodi f i cat I on»l 1st of <name>7 
C feature* I 1st of <naroe>l 
rproduct_nane*<name>3 
t f eatur e_cata log*<cata I og>3 
C working_catalog a <cata i og>3 
r.status»<status variable>1 



deck J decks J d s specifies the decks to be transmitted* 

modification J modifications * m t specifies the modifications to be 
trans ml tted. 

feature 1 features I f s specifies the features to be transmitted* 

product. name J pn J specif Ids the system or product to be used. 
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feature_cata log » fc * spaclfJ^s the feature catalog to fee used Hf 
any). 

working_cata log 1 wo J specifies the working catalog to he used* 
This parameter Is ignored if a feature catalog is used. 

status s see NOS/V'E error handling. 
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PPOC ass I gn. modi fi cations* ass I gn.inodi f I cati on* assm C 
feature* f i NAHE 
count* c » INTEGER » 1 

mod If Icatlon.descr iption* md s string « »N0 DESCRIPTION 1 
output* 5 f*l le * $LQCAU$GUTPUT 
author* a t string * $jofe(user) 
viorking.cataiog* wo * file 
status) 

PRC1C conpl le. source* coias C 

decks* deck* d : I 1st of name or KEY AIL 

select longer Iter I a; so s file*$null 

I nclude.iatest.changes* lie t boolean ■ falsa 

feature; f * I 1st of name or key ALL* NONE 

corp lie; c s file 

processor* p * string 

object. library* ol * list of name 

list* I i ft le - $13st 

I I st.oot Ions* llst.optlon* lo : list of key A F G R PA •• 

S X NONE DEFAULT « (S R) 
save. listings* si * list of key ALL* NONE, GOOD* BAD * NONE 
at ternate.pr aducts* al ternate. product* ap t ,. 

list of I I st of name 
a I ternate.bases* altar nate.b as e* ab i list of file or •• 

KEY NONE » NONE 
product. name* pn s name a OS 
build. level* bl t name 

f aature.cataiog* fo t file or KEY NONE » NONE 
feature. bui i d.ieval* fbl t name * OBJECT 
work ing.cata log* wc s file or KEY NONE « NONE 
*fork1r>g aa> buf !d_!ave!» **bi i name » OBJECT 
status ) 

PROC create. source* eras ( 

dacks* deck* d * list of nape 

mod i f i c at I on* m * name * $r e*iu I r^d 

source. group* sa s nai« ■ $raouired 

destlnatlon.group* dg « list of na»e or KEY NONE » Srequlred 

group* g * list of nana 

processor* p * string ■« •cybll 1 

author* a s string * $ job C user) 

deck. description* del * string « $P£QUIR£D 
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expand* e J boo lean 




same.as* sa s najae 




output* o J file » SI 1st 




product _name* pn « name * OS 




«orking,..catalog* mc i file or KEY NONE 


* NONE 


f eatur e_catalog* fc * file or KEY HON5 


• NONE 


status) 





PPOC displ ay.tforkl nj.env ironwent* diswe { 

dlsplay.optlons* dlspl ay_opt Ion* do * list of name or 

key all ■ all 
output* o 5 file » SOUTPUT 
status) 

^ROC edit.source* edis C 

nodi f| cation* mod* m ! NAME 1..9 

deck* d i NAMS 

output* o i FILE « $aUTPUT 

working. catalog* wc s FILE or KEY NOME * NONE 

status) 

PPOC enter_worki ng_anv irortrBent* entwe C 
author* a » string « $jobCuser) 
product«.na!ue* on * name * OS 
bu i I d_ level* bl i nm% 

feature.catalog* fc s file or KEY NOME * NONE 
featura_bui I d.levdl* f b I J nasae ■ OBJECT 
work ing_cata log* mc i file or KEY NONE » NONF 
Morklng.bui I d.laval* no I » name * OBJECT 
status) 

P$0C exi t^worklng^efivironaent* exjwe( 
status) 

PPOC extract_source* exts C 

decks* deck* d » I ist of name or KEY ALL 
sal ect ion.cr iter I a* so « file « $NULL 

I Ist* I J fl la * SLIST 

product.naiae* on J name * OS 

?eatura_catalog* fc * file or KEY NONE * NONE 

vtorklng_cataI09* ^c : file or KEY NONE * NONE 
status) 

?R0C format. cybl I. source* fores ( 
deck* d : name * Srequired 
mod If Icatlon* m * name ■ $required 
working_catal oa* vie s file or KEY NONE » NONE 
status) 



Integration and Development Guidelines and Conventions 

07/11/85 

A1.0 COMMAND SUMMARY 

mmm m mm mm mm mm mm mm ******** mm mm mm mmmmmmmmmmwm mm mmmmmmmmmmmmmmmmmmmmmmmmmmmm 

PROC gat. source* gets { 

decks* deck* d : list of name or KEY All 

source* s % file 

sel acti on.cr I ter i a* so J fi1e*$null 

Include. latest.coda* lie J boolean * false 

expand* a : boolean * false 

product.name* pn i name ■ OS 

build. level* bi * name 

f eature.eataiog* fc * file or KEY HOME * HONE 

f eature.bui Id. I aval* fbl : name * OBJECT 

working. catalog* mo • file or KEY NONE * NONE 

wor klng.bul Id.l aval * Mb I * name » OBJECT 

status) 

PROC Hst.intariocks* lisi C 

t lst.fi ie J file * SOUTPUT 
status) 

PROC jnaka.wodifi cation* m%km C 

wodi fleet lont m * NAHE l.*9 * SREQUXRED 

feature* f • name 

oiodif icat lon.descr ipt i on* md i list of string * $REQUIR£D 

autnor* a * string * $Job(user) 

working. catal og* wo ? file * $user 

status) 

PROC rep lace. source* raps ( 

source* s J file * SREQUIREP 

deck* d « NAME « 5RE0UIRE0 

modification* mod* m t NAME l.»9 « SREOUIRED 

worklng.catalog* wc s FILE or KEY NOME * NONE 

status) 

PROC set.working.anvironm^n t* setwe C 
author* a s string ■ SJobtuser) 
product. name* pn * name * CIS 
buHd.leve!* bl i nama 
tool. I ibrary.bul I J.J eve i * tlbl t name 
f eature.eataiog* fc s file or KEY NONE ■ NONE 
feature. bul I d.lave I* fbi i name * OBJECT 
working. catalog* *c t file or KEY NONE » NONE 
work ing.bul t d.l eve I* wbl * name * OBJECT 
status) 

PROC trans**?! t.to.f eatura.ca tal oo# tratfc ( 
decks* deck* d : list of name or key ALL 
modifications* modification* m * list of name or key ALL 
features* feature* f * i 1st of nape or key All 
se I act lon.cr iter I a* so J file • SNULL 
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feature. 


.cata 


log* 


fc 


• 
* 


file 


or 


KEY 


NONE 


m 


NONE 


Hork1ng.cata 


log* 


HC 


1 


file 


or 


KEY 


HONE 


s 


NONE 


status ) 























P&OC trans^i t_to_i ntegratf on* tratl C 

decks* deck* d * I ist of name or key ALL 

modifications* modification* m i list of name or key ALL 

features* feature* f J 1 ist of name or key ALL 

prcduct_na!nej pn J name « OS 

feature.catalofj* fc * file or KEY HOME « NONE 

working.catalog* wc * file or KEY NONE ■ NONE 

status) 
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